The Internet is becoming more and more popular, and users increasingly wish to access the Internet whilst on the move. Different types of mobile nodes (i.e. mobile communication units) may be employed for this purpose, for example a mobile telephone or a personal digital assistant (PDA) with wireless communication capability.
Increasingly, mobile users are accessing the Internet via different types of fixed or wireless access networks, for example a cellular radio communication network, such as a Universal Mobile Telecommunication System (UMTS) network, a HiperLAN/2 or IEEE 802.11b local area network, a Bluetooth local communication system, or fixed accesses such as the Ethernet, and so on. The data route between the mobile node and the Internet further comprises an Internet protocol subnet (IP subnet), such that the route is as follows: mobile node-access network-IP subnet-Internet (and reverse order for the data route from the Internet to the mobile node).
It is currently possible to seamlessly handover accessing of the Internet from one access network to another, for example by using a protocol known as Mobile-IP.
Traditional mobility support aims to provide continuous Internet connectivity to mobile hosts, thereby allowing individual mobile users to connect to the Internet whilst being mobile and moving their Internet access location. In contrast, network mobility support is concerned with situations where an entire network changes its point of attachment to the Internet topology and thus its accessibility in the topology. Such a network in movement can be called a Mobile Network.
There exist a large number of scenarios where such Mobile Networks exist. For example, a Personal Area Network (PAN, i.e. a network of several personal devices attached to an individual) is known whereby the PAN changes its point of attachment to the Internet topology whilst the user is walking in a shopping mall. In addition, a network may be embedded in a bus or aircraft, providing on-board Internet access to passengers. A passenger may use a single communication device (e.g. a laptop) or be itself a Mobile Network (e.g. a PAN). Notably, this configuration illustrates a case of a Mobile Network visiting a Mobile Network (i.e. nested mobility).
As such, a Mobile Network can be defined as a set of nodes composed of one or more IP-subnets attached to a Mobile Router (MR). These IP subnets may also be viewed as a mobile unit, with respect to the rest of the Internet, i.e. a MR and all its attached nodes (so called Mobile Network Nodes or MNNs).
A document [1] authored by Thierry Ernst, Hong-Yon Lach, IETF Internet-Draft draft-ernst-monet-terminology-00.txt, February 2002, describes a list of definitions for the Mobile Network terminology that can be applied in this application. In particular, the following terms may be defined as follows:                (i) A Local Fixed Node (LFN):        
A node permanently located within the Mobile Network and that does not change its point of attachment. A LFN can either be a Local Fixed Host (LFH) or a Local Fixed Router (LFR).                (ii) A Local Mobile Node (LMN):        
A local mobile node is one that belongs to the Mobile Network and changes its point of attachment from a link within the Mobile Network to another link within or outside the Mobile Network. In this regard, it can be assumed that the home link of the LMN is a link within the Mobile Network. A LMN can either be a Local Mobile Host (LMH) or a Local Mobile Router (LMR).                (iii) A Visiting Mobile Node (VMN):        
A VMN is one that does not belong to the Mobile Network, and changes its point of attachment from a link outside the Mobile Network to a link within the Mobile Network (i.e. the home link of the VMN is not a link within the Mobile Network). A VMN that attaches to a link within the Mobile Network obtains an address on that link. A VMN can either be a Visiting Mobile Host (VMH) or a Visiting Mobile Router (VMR).                (iv) A Mobile Network Prefix:        
A bit string that consists of a number of initial bits of an IP address, which identifies a Mobile Network within the Internet topology. Nodes belonging to the Mobile Network (i.e. at least MR, LFNs and LMNs) share the same IPv6 “network identifier”. For a single mobile IP-subnet, the Mobile Network Prefix is the “network identifier” of this subnet.                (v) An Egress Interface of a MR:        
This is the interface attached to the home link if the Mobile Network is at home. Alternatively, it is the interface attached to a foreign link if the Mobile Network is in a foreign network.                (vi) An Ingress Interface of a MR:        
This is the interface attached to a link inside the Mobile Network. The concept of egress and ingress interfaces can be extended to other types of nodes within a mobile network as follows:                                    (a) All network interfaces of hosts (fixed or mobile) in a mobile network are said to be egress interfaces. None of them is said to be an ingress interface.            (b) A fixed router in a mobile network (i.e. LFR) may have several egress and ingress interfaces. The type of each interface should be pre-configured on such routers. An egress interface is usually an interface on the shortest path to a Mobile Router. A fixed router in a mobile network should have at least one egress interface.                        (vii) A MR may have multiple Egress and Ingress interfaces.        (viii) A mobile network may have multiple MRs.        
Recently, there has been a lot of interest and research into the Mobile IPv6 specification, as described in the document [2] authored by David B. Johnson: IETF Internet-Draft draft-ietf-mobileip-ipv6-15.txt, July 2001. A major concern with Mobile Ipv6 is that the research has proven that the IPv6 standard is currently unable to adequately address network mobility. In particular, the document [3] authored by Thierry Ernst and Hong-Yon Lach: IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, June 2001, details problems encountered with Mobile-IPv6 in supporting Mobile Networks.
In summary, it has been determined that even if a MR's Home Agent (HA) is able to intercept packets addressed to MNNs that are operating behind the MR, the MR's HA is clearly unable to encapsulate them to the care-of-address of the appropriate MR. Note that every data packet has a source address and a destination address. A tunnelled packet is a packet that encapsulates in it another packet. Thus, the encapsulating packet has a pair of source and destination addresses. A further encapsulated packet has additional source and destination addresses.
The lack of knowledge of a true location of a particular MNN results from the HA not knowing any (never mind a preferred) data route to the Mobile Network, once it has moved to a ‘visited’ location. Unfortunately, when a MR registers with its HA the MR only informs the HA to record a host-specific route in its routing table. The inventors of the present invention have recognised that a preferred network route generated using the mobile network address (prefix, prefix length and care-of-address) of the appropriate MR would greatly assist in this matter.
In the field of this invention, the Mobile IPv4 specification, detailed in [4] C. Perkins, IETF RFC 3220, “IP Mobility Support for IPv4”, Standards Track, January 2002, describes how Network Mobility can be supported in the case of IPv4 mobility. However, it has also been determined that IPv4 does not support route optimisation for MNNs behind the MR.
Thus, all the (incoming and outgoing) traffic between a MNN and its corresponding nodes (CNs) is passed to the MR's Home Agent. This problem is exacerbated in the case of nested mobility, which is where a CN wishes to pass data to a MNN that is behind a number of MR links, or a mobile node visiting a mobile network. In the case of nested mobility, the packet will thus be encapsulated several times as a result of being routed through all of the Home Agents of all the nested MRs. This is clearly inefficient routing.
Similarly, in the case of IPv6, the document [5] authored by T. J. Kniveton: IETF Internet-Draft draft-kniveton-mobrtr-00.txt, November 2001 describes how to support mobile networks with no modifications to Mobile IP (v4 or v6). The mechanism proposed to address the support of nested mobility is described with respect to FIG. 2. It suffers from the same problem of multiple tunnelling by the Home Agents of the nested mobile routers as described in the previous paragraph. When a MR, for example MR2 260, has attached to a visited network 110 (via another Mobile Network MR1 link), a bi-directional tunnel 210, 215, 220 is established between MR2 260 and its HA-HA2 250. When a node, for example LFN2 165, is attached to MR2 260 and wishes to send an IP packet to a CN, say CN2 255, via the Internet 115, that packet is tunnelled by MR2 260 (to HA2 250) and again by MR1 150 (to HA1 240). The multiple-tunnelled data packet is then passed to the HA of the latest MR to tunnel the data, namely to HA1 240. HA1 240 then forwards it to the intended recipient CN2 255 via the source MR's HA, namely HA2 250.
This proposed data routing method, and the problems associated with it, are best described by way of an example. Thus, let us assume that LFN2 165 sends a data packet to CN2 255. The data packet is first routed 205 towards MR2 260. The data packet is then tunnelled by MR2 260 to be sent to HA2 250. This tunnelling process of the data packet from MR2 260 to HA2 250 is itself, by necessity, first routed 210 towards its linked MR, namely MR1 150. MR1 150 further tunnels the data and forwards 215 the multiple-tunnelled packet to its HA, namely HA1 240. HA1 240 de-tunnels the data packet, as tunnelled by MR1 150 and forwards 220 the partially de-tunnelled packet to its original intended recipient, HA2 250. HA2 250 further de-tunnels the packet, as tunnelled by MR2 260, and forwards 225 the wholly de-tunnelled data packet to CN2 255.
Clearly, the solution proposed does not provide any support for route optimisation, since both inbound and outbound packets are routed through the Home Agent of both MRs 150, 260. In fact, packets from CN2 255 addressed to LFN2 165 will follow the same path (in reverse order) and will then be encapsulated by each Home Agent 240, 250 of each of the nested MRs 150, 260. Once again, this is clearly inefficient routing, particularly for a practical situation whereby there may be many more than two levels in the nested network.
The solution presented in a document authored by Thierry Ernst and Hong-Yon Lach: IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, June 2001, proposes a means for supporting network mobility in the framework of Mobile IPv6. This solution introduces the following concept: when a Mobile Router roams to a visited network, it sends a Prefix Scope Binding Update to its Home Agent (HA). Unlike a classical Mobile IPv6 Binding Update message, a Prefix Scope Binding Update does not bind a home address with a care-of address.
In contrast, the MR Prefix is bound with the MR care-of address, for a particular MR. Upon reception of a packet whose prefix matches with the MR prefix, the Home Agent must then tunnel the packet to the MR care-of-address that has been identified as being able to deliver the tunnelled packet to the intended recipient. Likewise, a MR may send prefix-scope BUs to the corresponding nodes of the nodes it serves. This solution brings a more efficient support of mobile networks to Mobile IPv6, since it may provide a limited improvement to route optimisation.
However, the scope of this draft has explicitly excluded the case of nested mobility, which presents a significant hurdle to efficient route optimisation. As such, the solution proposed in the Thierry Ernst document, IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, June 2001, fails to provide a useful solution to route optimisation in many practical situations. Again, the problems that emanate from this document, particularly in the case of nested mobility, are best highlighted in an example situation.
Referring now to FIG. 3, a mechanism for routing data packets in an IPv6 network using the proposal of Thierry Ernst: IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, June 2001. Notably, the problems emanating from using this mechanism in a nested mobility are highlighted.
A mobile router MR1 150 is attached to a visited link 110. A mobile router MR2 260 is attached to MR1's link 155. A local fixed node LFN2 165 is attached to MR2's link 230. Again, let us assume that LFN2 165 is attempting to communicate with a corresponding node CN2 255.
Let us further assume that, at the beginning of the simple scenario detailed in FIG. 3, MR1 150 and MR2 260 have already sent BU messages to their respective HAs 240, 250. That is, HA1 240 knows that MR1's 150 prefix is reachable at MR1's care-of address. Similarly, HA2 250 knows that MR2's 260 prefix is reachable at MR2's care-of address.
When a data packet is sent from CN2 255 to LFN2 165, CN2 255 has no knowledge about LFN2's 165 actual location. Thus, the data packet that it sends is therefore routed 325 towards home link-2 105. HA2 250 intercepts the data packet and tunnels it to MR2's care-of address. This can be understood, as HA2 250 knows that MR2's prefix is reachable at MR2's care-of address.
This tunnelled packet (from HA2 250 to MR2's 260 care-of address) is routed 320 toward link-1 245, since MR2's 260 care-of address matches MR1's 150 prefix. HA1 240 intercepts the data packet and tunnels it to MR1's care-of address, namely towards the visited link 110, since HA1 240 knows that MR1's prefix is reachable at MR1's care-of address.
MR1 150 then de-tunnels the data packet received from HA1 240. MR1 150 then forwards the content to the original recipient, MR2 260. Meanwhile, MR1 150 sends a Binding Update to the sender of the encapsulated packet (that is HA2 250) to inform it that MR1's prefix is reachable at MR1's care-of address. Note that from MR1's point of view, HA2 250 is a Correspondent Node and not its Home Agent (i.e. the ‘H’ bit in the BU is not set). It is up to the HA2 250 to accept this Binding Update or not.
MR2 260 de-tunnels the data packet that it received (i.e. the portion of the data packet that had been encapsulated by HA2 250) and forwards the content (the initial packet from CN2 255) to LFN2 165. Meanwhile, MR2 260 sends a Binding Update message to the sender of the encapsulated packet (that is, CN2 255) to inform it that MR2's prefix (covering the LFN2 165 address) is reachable at M2's care-of address. This information is stored in the CN's binding cache 370.
Once an initial packet has reached its destination, transmission of a second or subsequent packet from CN2 255 to LFN2 165 leads to the scenario depicted in FIG. 4. After having reviewed its binding cache 370, CN2 255 recognises that LFN2 165 is reachable at MR2's care-of address.
Thus, it sends the data packet to MR2's care-of-address with a routing header for LFN2 165. MR2's care-of-address belongs to MR1's link and is therefore routed towards Home Link-1 245. In this manner, a minor improvement to route optimisation is achieved by the bypassing of the transmission of the data packet to, and from, HA2 250.
HA1 240 then intercepts the data packet and tunnels the packet to MR1's care-of address, since HA1 240 knows that MR1's prefix is reachable at MR1's care-of address.
MR1 150 de-tunnels the packet from HA1 240 and forwards the content to the mobile router MR2 260 of the originally intended recipient, LFN2 165. Meanwhile, MR1 150 sends a Binding Update to the sender of the encapsulated packet (that is, CN2 255) to inform it that MR1's prefix is reachable at MR1's care-of address.
When receiving the original packet as sent by CN2 255, MR2 260 replaces its address in the destination field of the packet with the address contained in the routing header (that is, LFN2 165) and forwards the data packet to the ultimate recipient.
The inventors of the present invention have identified a significant problem with the scenario depicted in FIG. 4. All subsequent packets from CN2 255 to LFN2 165 will be routed in exactly the same manner as the second data packet. That is, there will be no subsequent improvement towards route optimisation. This is more clearly shown in respect of FIG. 5.
Referring now to FIG. 5, a known binding cache 500 is illustrated. The binding cache comprises a list of entries, specific to each MR in a nested mobility scenario. The binding cache entries include, for example a MR3 prefix and prefix length 530, with a link 532 to a determined MR3 care-of-address 534, if one has been determined. The MR3 entry 535 is linked 536 to the next entry in the binding cache, namely that for MR2. The MR2 prefix and prefix length 520, includes a link 522 to a determined MR2 care-of-address 524, if one has been determined. A similar arrangement and link 526 is performed to MR1, and so on.
In addition, the binding cache entries include a flag entry (not shown). A ‘P’ flag is the “Prefix Scope Registration” flag. When it is set, a “Home Address” field is filled with the Mobile Network prefix (the prefix that is advertised by the Mobile Router) and the “Prefix Length” corresponds to the length of the Mobile Network prefix.
It is specified in the document by Thierry Ernst: IETF Internet-Draft draft-ernst-mobileip-v6-network-02.txt, June 2001, that the Binding Cache is searched for an entry corresponding to the destination address of the packet in one pass. As a result of the search, either nothing has been found (no entry), or the full address has been found (128-bit match for an IPv6 address, P flag unset), or the first bits of the destination address match with a registered prefix for the registered prefix length. In the latter case, the destination is located in a mobile network.
Therefore, with reference to FIG. 4, when CN2 255 has to send a packet to LFN2 165, CN2 255 still reviews its binding cache and finds the entry ‘MR2 260 prefix reachable at MR2 260 Co@’ 520, 524. CN2 255 does not even consider the entry ‘MR1 150 prefix reachable at MR1Co@’ 510, 514, as this would appear to have no bearing on the LFN2 address. The inventors have recognised that this deficiency results from the LFN2 165 address being unrelated to the MR1 prefix. The fact that MR2 260 Co@ belongs to MR1 prefix is neither seen, nor even used by CN2 255.
Consequently, the only optimisation that the Thierry Ernst proposal can support is related to the HA (HA2 250) of the MR (MR2 260) serving the communicating MNN (LFN2 165 in the above example). This solution describes indeed a means for having packets be sent directly from CN2 255 to HA1 240, instead of CN2 255 to HA2 250 and thereafter to HA1 240. However, if there were n successive levels of nested mobility, this solution provides minimal route optimisation, no more than having a CN2 255→HAn−1→HAn−2→ . . . →HA1 path instead of CN2 255→HAn→HAn−1→HAn−2→ . . . →HA1 path. This proposal is therefore still clearly inefficient, particularly in the case of nested networks.
A need therefore arises for a mechanism, apparatus and associated methods to support route optimisation in Network mobility, especially in the case of IPv6. In particular, a need has arisen to support route optimisation in the case of nested mobility, wherein the aforementioned problems are substantially alleviated.